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TLS DNSSEC Chain Extension 


Abstract 


This document describes an experimental TLS extension for the in-band transport of the 
complete set of records that can be validated by DNSSEC and that are needed to perform DNS- 
Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need 
to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the 
extension conveys a denial-of-existence proof that can be validated. 


This experimental extension is developed outside the IETF and is published here to guide 
implementation of the extension and to ensure interoperability among implementations. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This is a 
contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has 
chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9102. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


This document describes an experimental TLS [RFC5246] [RFC8446] extension for in-band 
transport of the complete set of resource records (RRs) validated by DNSSEC [RFC4033] [RFC4034] 
[RFC4035]. This extension enables a TLS client to perform DANE authentication [RFC6698] 
[RFC7671] of a TLS server without the need to perform out-of-band DNS lookups. Retrieval of the 
required DNS records may be unavailable to the client [DISCOVERY] or may incur undesirable 
additional latency. 


The extension described here allows a TLS client to request that the TLS server return the 
DNSSEC authentication chain corresponding to its DNSSEC-validated DANE TLSA resource record 
set (RRset) or authenticated denial of existence of such an RRset (as described in Section 2.3.1). If 
the server supports this extension, it performs the appropriate DNS queries, builds the 
authentication chain, and returns it to the client. The server will typically use a previously 
cached authentication chain, but it will need to rebuild it periodically as described in Section 4. 
The client then authenticates the chain using a preconfigured DNSSEC trust anchor. 


In the absence of TLSA records, this extension conveys the required authenticated denial of 
existence. Such proofs are needed to securely signal that specified TLSA records are not available 
so that TLS clients can safely fall back to authentication based on Public Key Infrastructure X.509 
(PKIX, sometimes called WebPKI) if allowed by local policy. These proofs are also needed to avoid 
downgrade from opportunistic authenticated TLS (when DANE TLSA records are present) to 
unauthenticated opportunistic TLS (in the absence of DANE). Denial-of-existence records are also 
used by the TLS client to clear extension pins that are no longer relevant, as described in Section 
SZ 


This extension supports DANE authentication of either X.509 certificates or raw public keys, as 
described in the DANE specification [RFC6698] [RFC7671] [RFC7250]. 


This extension also mitigates against an unknown key share (UKS) attack [DANE-UKS] when 
using raw public keys since the server commits to its DNS name (normally found in its 
certificate) via the content ofthe returned TLSA RRset. 
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This experimental extension is developed outside the IETF and is published here to guide 
implementation of the extension and to ensure interoperability among implementations. 


1.1. Scope of the Experiment 


The mechanism described in this document is intended to be used with applications on the wider 
internet. One application of TLS well suited for the TLS DNSSEC Chain extension is DNS over TLS 
[RFC7858]. In fact, one of the authentication methods for DNS over TLS is the mechanism 
described in this document, as specified in Section 8.2.2 of [RFC8310]. 


The need for this mechanism when using DANE to authenticate a DNS-over-TLS resolver is 
obvious, since DNS may not be available to perform the reguired DNS lookups. Other 
applications of TLS would benefit from using this mechanism as well. The client sides of those 
applications would not be reguired to be used on endpoints with a working DNSSEC resolver in 
order for them to use the DANE authentication ofthe TLS service. Therefore, we invite other TLS 
services to try out this mechanism as well. 


In the TLS Working Group, concerns have been raised that the pinning technigue as described in 
Section 7 would complicate deployability of the TLS DNSSEC chain extension. The goal ofthe 
experiment is to study these complications in real-world deployments. This experiment hopefully 
will give the TLS Working Group some insight into whether or not this is a problem. 


If the experiment is successful, it is expected that the findings of the experiment will result in an 
updated document for Standards Track approval. 


1.2. Reguirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2. DNSSEC Authentication Chain Extension 


2.1. Protocol, TLS 1.2 


A client MAY include an extension oftype dnssec. chain in the (extended) ClientHello. The 
extension data field of this extension consists of the server's 16-bit TCP port number in 
network (big-endian) byte order. Clients sending this extension MUST also send the Server Name 
Identification (SNI) extension [RFC6066]. Together, these make it possible for the TLS server to 
determine which authenticated TLSA RRset chain needs to be used for the dnssec. chain 
extension. 
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When a server that implements (and is configured to enable the use of) this extension receives a 
dnssec chain extension in the ClientHello, it MUST first check whether the requested TLSA RRset 
(based on the port number in this extension and hostname in the SNI extension) is associated 
with the server. If the extension, the SNI hostname, or the port number is unsupported, the 
server's extended ServerHello message MUST NOT include the dnssec chain extension. 


Otherwise, the server's extended ServerHello message MUST contain a serialized authentication 
chain using the format described below. If the server does not have access to the requested DNS 
chain -- for example, due to a misconfiguration or expired chain -- the server MUST omit the 
extension rather than send an incomplete chain. Clients that are expecting this extension MUST 
interpret this as a downgrade attack and MUST abort the TLS connection. Therefore, servers 
MUST send denial-of-existence proofs unless, for the particular application protocol or service, 
clients are expected to continue even inthe absence of such a proof. As with all TLS extensions, if 
the server does not support this extension, it will not return any authentication chain. 


The set of supported combinations of a port number and SNI name may be configured explicitly 
by server administrators or could be inferred from the available certificates combined with a list 
of supported ports. It is important to note that the client's notional port number may be different 
from the actual port on which the server is receiving connections. 


Differences between the client's notional port number and the actual port at the server could be 
a result of intermediate systems performing network address translation or a result of a redirect 
via HTTPS or SVCB records (both defined in [DNSOP-SVCB-HTTPS]). 


Though a DNS zone's HTTPS or SVCB records may be signed, a client using this protocol might not 
have direct access to a validating resolver and might not be able to check the authenticity of the 
target port number or hostname. In order to avoid downgrade attacks via forged DNS records, 
the SNI name and port number inside the client extension MUST be based on the original SNI 
name and port and MUST NOT be taken from the encountered HTTPS or SVCB record. The client 
supporting this document and HTTPS or SVCB records MUST still use the HTTPS or SVCB records 
to select the target transport endpoint. Servers supporting this extension that are targets of 
HTTPS or SVCB records MUST be provisioned to process client extensions based on the client's 
logical service endpoint's SNI name and port asitis prior to HTTPS or SVCB indirection. 


2.2. Protocol, TLS 1.3 


In TLS 1.3 [RFC8446], when the server receives the dnssec. chain extension, it adds its 
dnssec chain extension to the extension block of the Certificate message containing the end- 
entity certificate being validated rather than to the extended ServerHello message. 


The extension protocol behavior otherwise follows that specified for TLS version 1.2 [RFC5246]. 
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2.3. DNSSEC Authentication Chain Data 


The extension data field of the client's dnssec. chain extension MUST contain the server's 16- 
bit TCP port number in network (big-endian) byte order: 


struct { 
uint16 PortNumber; 
} DnssecChainExtension; 


The extension_data field of the server's dnssec_chain extension MUST contain a DNSSEC 
authentication chain encoded in the following form: 


struct { 

uint16 ExtSupportLifetime; 

opaque AuthenticationChain<1..2416-1> 
} DnssecChainExtension; 


The ExtSupportLifetime value is the number of hours that the TLS server has committed itself to 
serving this extension. A value of zero prohibits the client from unilaterally requiring ongoing 
use of the extension based on prior observation of its use (extension pinning). This is further 
described in Section 7. 


The AuthenticationChain is composed of a sequence of uncompressed wire format DNS RRs 
(including all requisite RRSIG RRs [RFC4034]) in no particular order. The format of the resource 
record is described in [RFC1035], Section 3.2.1. 


RR = { owner, type, class, TTL, RDATA length, RDATA } 
The order of returned RRs is unspecified, and a TLS client MUST NOT assume any ordering of RRs. 


Use of DNS wire format records enables easier generation of the data structure on the server and 
easier verification of the data on the client by means of existing DNS library functions. 


The returned RRsets MUST contain either the TLSA RRset or the associated denial-of-existence 
proof of the configured (and requested) SNI name and port. In either case, the chain of RRsets 
MUST be accompanied by the full set of DNS records needed to authenticate the TLSA record set 
or its denial of existence up the DNS hierarchy to either the root zone or another trust anchor 
mutually configured by the TLS server and client. 


When some subtree in the chain is subject to redirection via DNAME records, the associated 
inferred CNAME records need not be included. They can be inferred by the DNS validation code 
in the client. Any applicable ordinary CNAME records that are not synthesized from DNAME 
records MUST be included along with their RRSIGs. 
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In case of a server-side DNS problem, servers may be unable to construct the authentication 
chain and would then have no choice but to omit the extension. 


In the case of a denial-of-existence response, the authentication chain MUST include all DNSSEC- 
signed records, starting with those from the trust anchor zone, that chain together to reach a 
proof of either: 


* the nonexistence of the TLSA records (possibly redirected via aliases) or 


* an insecure delegation above or at the (possibly redirected) owner name of the requested 
TLSA RRset. 


Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the 
DNS tree. In this case, the authentication chain structure needs to include DS and DNSKEY record 
sets that cover all the necessary branches. 


The returned chain SHOULD also include the DNSKEY RRsets of all relevant trust anchors 
(typically just the root DNS zone). Though the same trust anchors are presumably also 
preconfigured in the TLS client, including them in the response from the server permits TLS 
clients to use the automated trust anchor rollover mechanism defined in [RFC5011] to update 
their configured trust anchors. 


Barring prior knowledge of particular trust anchors that the server shares with its clients, the 
chain constructed by the server MUST be extended as closely as possible to the root zone. 
Truncation of the chain at some intermediate trust anchor is generally only appropriate inside 
private networks where all clients and the server are expected to be configured with DNS trust 
anchors for one or more non-root domains. 


The following is an example of the records in the AuthenticationChain structure for the HTTPS 
server at www.example.com, where there are zone cuts at com and example .com (record data are 
omitted here for brevity): 


-443. tcp.www.example.com. TLSA 

RRSIG( 443. tcp. www.example.com. TLSA) 
example.com. DNSKEY 

RRSIG(example.com. DNSKEY) 
example.com. DS 

RRSIG(example.com. DS) 


com. DNSKEY 
RRSIG(com. DNSKEY) 
com. DS 

RRSIG(com. DS) 

. DNSKEY 


RRSIG(. DNSKEY) 
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The following is an example of denial of existence for a TLSA RRset at 
-443. tcp.www.example. com. The NSEC record in this example asserts the nonexistence of both 
the requested RRset and any potentially relevant wildcard records. 


www .example.com. IN NSEC example.com. A NSEC RRSIG 
RRSIG(www .example.com. NSEC) 
example.com. DNSKEY 
RRSIG(example.com. DNSKEY) 
example.com. DS 
RRSIG(example.com. DS) 

com. DNSKEY 

RRSIG(com. DNSKEY) 

com. DS 

RRSIG(com. DS) 

. DNSKEY 

RRSIG(. DNSKEY) 


The following is an example of (hypothetical) insecure delegation of example. com from the .com 
zone. This example shows NSEC3 records [RFC5155] with opt-out. 


; covers example.com 

onib9mgub9h@rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - 
onib9mgub9harml3cdf5bgrj59dkjhv1 NS DS RRSIG) 

RRSIG(onib9mgub9harml3cdf5bgrj59dkjhvj.com. NSEC3) 

; covers *.com 

3r12r262eg8n1ap5olhae7mah2ah89hi.com. NSEC3 (1 1 0 - 
3r12r262eg8n1ap5olhae7mah2ah89hk NS DS RRSIG) 

RRSIG(3r12r262eg@n1ap5o0lhae7mah2ah@9hj.com. NSEC3) 

; closest-encloser "com" 

ck0pojmg8741jref7efn8430qvit8bsm.com. NSEC3 (1 1 0 - 
ck0pojmg8741jref7efn8430qvit8bsm.com 
NS SOA RRSIG DNSKEY NSEC3PARAM) 

RRSIG(ck0pojmg8741jref7efn8430qvit8bsm.com. NSEC3) 

com. DNSKEY 

RRSIG(com. DNSKEY) 

com. DS 

RRSIG(com. DS) 

. DNSKEY 

RRSIG(. DNSKEY) 


2.3.1. Authenticated Denial of Existence 


TLS servers that support this extension and respond to a request containing this extension that 
do not have a signed TLSA record for the configured (and requested) SNI name and port MUST 
instead return a DNSSEC chain that provides authenticated denial of existence for the configured 
SNI name and port. A TLS client receiving proof of authenticated denial of existence MUST use an 
alternative method to verify the TLS server identity or close the connection. Such an alternative 
could be the classic PKIX model of preinstalled root certificate authorities (CAs). 
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Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the 
following facts: 


* The TLSA record (after any DNSSEC-validated alias redirection) does not exist. 


e There is no signed delegation to a DNS zone that is either an ancestor of or the same as the 
TLSA record name (after any DNSSEC-validated alias redirection). 


3. Construction of Serialized Authentication Chains 


This section describes a possible procedure for the server to use to build the serialized DNSSEC 
chain. 


When the goal is to perform DANE authentication [RFC6698] [RFC7671] of the server, the DNS 
record set to be serialized is a TLSA record set corresponding to the server's domain name, 
protocol, and port number. 


The domain name of the server MUST be that included in the TLS server name (SNI) extension 
[RFC6066]. If the server does not recognize the SNI name as one of its own names but wishes to 
proceed with the handshake rather than abort the connection, the server MUST NOT send a 
dnssec_chain extension to the client. 


The name in the client's SNI extension MUST NOT be CNAME expanded by the server. The TLSA 
base domain (Section 3 of [RFC6698]) SHALL be the hostname from the client's SNI extension, and 
the guidance in Section 7 of [RFC7671] does not apply. See Section 9 for further discussion. 


The TLSA record to be queried is constructed by prepending underscore-prefixed port number 
and transport name labels to the domain name as described in [RFC6698]. The port number is 
taken from the client's dnssec_chain extension. The transport name is "tcp" for TLS servers and 
"udp" for DTLS servers. The port number label is the leftmost label, followed by the transport 
name label, followed by the server domain name (from SNI). 


The components of the authentication chain are typically built by starting at the target record set 
and its corresponding RRSIG, then traversing the DNS tree upwards towards the trust anchor 
zone (normally the DNS root). For each zone cut, the DNSKEY, DS RRsets, and their signatures are 
added. However, see Section 2.3 for specific processing needed for aliases. If DNS response 
messages contain any domain names utilizing name compression [RFC1035], then they MUST be 
uncompressed prior to inclusion in the chain. 


Implementations of EDNS CHAIN query requests as specified in [RFC7901] may offer an easier 
way to obtain all of the chain data in one transaction with an upstream DNSSEC-aware recursive 
server. 


4. Caching and Regeneration of the Authentication Chain 


DNS records have Time To Live (TTL) parameters, and DNSSEC signatures have validity periods 
(specifically signature expiration times). After the TLS server constructs the serialized 
authentication chain, it SHOULD cache and reuse it in multiple TLS connection handshakes. 
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However, it SHOULD refresh and rebuild the chain as TTL values require. A server 
implementation could carefully track TTL parameters and requery component records in the 
chain correspondingly. Alternatively, it could be configured to rebuild the entire chain at some 
predefined periodic interval that does not exceed the DNS TTLs of the component records in the 
chain. If a record in the chain has a very short TTL (e.g., 0 up to a few seconds), the server MAY 
decide to serve the authentication chain a few seconds past the minimum TTL in the chain. This 
allows an implementation to dedicate a process or single thread to building the authentication 
chain and reuse it for more than a single waiting TLS client before needing to rebuild the 
authentication chain. 


5. Expired Signatures in the Authentication Chain 


A server MAY look at the signature expiration of RRSIG records. While these should never expire 
before the TTL of the corresponding DNS record is reached, if this situation is nevertheless 
encountered, the server MAY lower the TTL to prevent serving expired RRSIGs if possible. If the 
signatures are already expired, the server MUST still include these records in the authentication 
chain. This allows the TLS client to either support a grace period for staleness or give a detailed 
error, either as a log message or a message to a potential interactive user of the TLS connection. 
The TLS client SHOULD handle expired RRSIGs similarly to how it handles expired PKIX 
certificates. 


6. Verification 


A TLS client performing DANE-based verification might not need to use this extension. For 
example, the TLS client could perform DNS lookups and DANE verification without this 
extension, or it could fetch authentication chains via another protocol. If the TLS client already 
possesses a valid TLSA record, it MAY bypass use of this extension. However, if it includes this 
extension, it MUST use the TLS server reply to update the extension pinning status ofthe TLS 
server's extension lifetime. See Section 7. 


A TLS client making use of this specification that receives a valid DNSSEC authentication chain 
extension from a TLS server MUST use this information to perform DANE authentication ofthe 
TLS server. In order to perform the validation, it uses the mechanism specified by the DNSSEC 
protocol [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC 
validation engine or library. 


If the authentication chain validates, the TLS client then performs DANE authentication of the 
server according to the DANE TLS protocol [RFC6698] [RFC7671]. 


Clients MAY cache the server's validated TLSA RRset to amortize the cost of receiving and 
validating the chain over multiple connections. The period of such caching MUST NOT exceed the 
TTL associated with those records. A client that possesses a validated and unexpired TLSA RRset 
or the full chain in its cache does not need to send the dnssec_chain extension for subsequent 
connections to the same TLS server. It can use the cached information to perform DANE 
authentication. 
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Note that when a client and server perform TLS session resumption, the server sends no 
dnssec chain. Thisis particularly clear with TLS 1.3, where the certificate message to which the 
chain might be attached is also not sent on resumption. 


7. Extension Pinning 


TLS applications can be designed to unconditionally mandate this extension. Such TLS clients 
requesting this extension would abort a connection to a TLS server that does not respond with an 
extension reply that can be validated. 


However, in a mixed-use deployment of PKIX and DANE, there is the possibility that the security 
of a TLS client is downgraded from DANE to PKIX. This can happen when a TLS client connection 
is intercepted and redirected to a rogue TLS server presenting a TLS certificate that is considered 
valid from a PKIX point of view but does not match the legitimate server's TLSA records. By 
omitting this extension, such a rogue TLS server could downgrade the TLS client to validate the 
mis-issued certificate using only PKIX and not via DANE, provided the TLS client is also not able 
to fetch the TLSA records directly from DNS. 


The ExtSupportLifetime element of the extension provides a countermeasure against such 
downgrade attacks. Its value represents the number of hours that the TLS server (or cluster of 
servers serving the same server name) commits to serving this extension in the future. This is 
referred to as the "pinning time" or "extension pin" of the extension. A non-zero extension pin 
value received MUST ONLY be used if the extension also contains a valid TLSA authentication 
chain that matches the server's certificate chain (the server passes DANE authentication based on 
the enclosed TLSA RRset). 


Any existing extension pin for the server instance (name and port) MUST be cleared on receipt of 
a valid denial of existence for the associated TLSA RRset. The same also applies if the client 
obtained the denial-of-existence proof via another method, such as through direct DNS queries. 
Based on the TLS client's local policy, it MAY then terminate the connection or MAY continue 
using PKIX-based server authentication. 


Extension pins MUST also be cleared upon the completion of a DANE-authenticated handshake 
with a server that returns a dnssec_chain extension with a zero ExtSupportLifetime. 


Upon completion of a fully validated handshake with a server that returns a dnssec_chain 
extension with a non-zero ExtSupport lifetime, the client MUST update any existing pin lifetime 
for the service (name and port) to a value that is not longer than that indicated by the server. The 
client MAY, subject to local policy, create a previously nonexistent pin, again for a lifetime that is 
not longer than that indicated by the server. 


The extension support lifetime is not constrained by any DNS TTLs or RRSIG expirations in the 
returned chain. The extension support lifetime is the time for which the TLS server is committing 
itself to serve the extension; it is not a validity time for the returned chain data. During this 
period, the DNSSEC chain may be updated. Therefore, the ExtSupportLifetime value is not 
constrained by any DNS TTLs or RRSIG expirations in the returned chain. 
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Clients MAY implement support for a subset of DANE certificate usages. For example, clients may 
support only DANE-EE(3) and DANE-TA(2) [RFC7218], only PKIX-EE(1) and PKIX-TA(0), or all four. 
Clients that implement DANE-EE(3) and DANE-TA(2) MUST implement the relevant updates in 
[RFC7671]. 


For a non-zero saved value ("pin") of the ExtSupportLifetime element of the extension, TLS 
clients that do not have a cached TLSA RRset with an unexpired TTL MUST use the extension for 
the associated name and port to obtain this information from the TLS server. This TLS client then 
MUST require that the TLS server respond with this extension, which MUST contain a valid TLSA 
RRset or proof of nonexistence of the TLSA RRset that covers the requested name and port. Note 
that a nonexistence proof or proof of insecure delegation will clear the pin. The TLS client MUST 
reguire this for as long asthe time period specified by the pin value, independent ofthe DNS 
TTLs. During this process, if the TLS client fails to receive this information, it MUST either abort 
the connection or delay communication with the server via the TLS connection until it is able to 
obtain valid TLSA records (or proof of nonexistence) out of band, such as via direct DNS lookups. 
If attempts to obtain the TLSA RRset out of band fail, the client MUST abort the TLS connection. It 
MAY try a new TLS connection again (for example, using an exponential back-off timer) in an 
attempt to reach a different TLS server instance that does properly serve the extension. 


A TLS client that has a cached validated TLSA RRset and a valid non-zero extension pin time MAY 
still refrain from reguesting the extension as long as it uses the cached TLSA RRset to 
authenticate the TLS server. This RRset MUST NOT be used beyond its received TTL. Once the 
TLSA RRset's TTL has expired, the TLS client with a valid non-zero extension pin time MUST 
request the extension and MUST abort the TLS connection if the server responds without the 
extension. A TLS client MAY attempt to obtain the valid TLSA RRset by some other means before 
initiating a new TLS connection. 


Note that reguiring the extension is NOT the same as reguiring the use of DANE TLSA records or 
even DNSSEC. A DNS zone operator may at any time delete the TLSA records or even remove the 
DS records to disable the secure delegation of the server's DNS zone. The TLS server will replace 
the chain with the corresponding denial-of-existence chain when it updates its cached TLSA 
authentication chain. The server's only obligation is continued support for this extension. 


8. Trust Anchor Maintenance 


The trust anchor may change periodically, e.g., when the operator ofthe trust anchor zone 
performs a DNSSEC key rollover. TLS clients using this specification MUST implement a 
mechanism to keep their trust anchors up to date. They could use the method defined in 
[RFC5011] to perform trust anchor updates in-band in TLS by tracking the introduction of new 
keys seen inthe trust anchor DNSKEY RRset. However, alternative mechanisms external to TLS 
may also be utilized. Some operating systems may have a system-wide service to maintain and 
keep the root trust anchor up to date. In such cases, the TLS client application could simply 
reference that asits trust anchor, periodically checking whether it has changed. Some 
applications may prefer to implement trust anchor updates as part oftheir automated software 
updates. 
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9. Virtual Hosting 


Delivery of application services is often provided by a third party on behalf of the domain owner 
(hosting customer). Since the domain owner may want to be able to move the service between 
providers, non-zero support lifetimes for this extension should only be enabled by mutual 
agreement between the provider and domain owner. 


When CNAME records are employed to redirect network connections to the provider's network, 
as mentioned in Section 3, the server uses the client's SNI hostname as the TLSA base domain 
without CNAME expansion. When the certificate chain for the service is managed by the 
provider, it is impractical to coordinate certificate changes by the provider with updates in the 
hosting customer's DNS. Therefore, the TLSA RRset for the hosted domain is best configured as a 
CNAME from the customer's domain to a TLSA RRset that is managed by the provider as part of 
delivering the hosted service. For example: 


; Customer DNS 

www .example.com. IN CNAME node1.provider.example. 

443. tcp.www.example.com. IN CNAME _dane443.node1.provider.example. 
; Provider DNS 

node1.provider.example. IN A 192.0.2.1 

-dane443 .node1.provider .example. IN TLSA 1 1 1 


Clients that obtain TLSA records directly from DNS, bypassing this extension, may perform 
CNAME expansion as in Section 7 of [RFC7671]. If TLSA records are associated with the fully 
expanded name, that name may be used as the TLSA base domain and SNI name for the TLS 
handshake. 


To avoid confusion, it is RECOMMENDED that server operators not publish TLSA RRs (_port._tcp. + 
base domain) based on the expanded CNAMES used to locate their network addresses. Instead, 
the server operator SHOULD publish TLSA RRs at an alternative DNS node (as in the example 
above), to which the hosting customer will publish a CNAME alias. This results in all clients 
(whether they obtain TLSA records from DNS directly or employ this extension) seeing the same 
TLSA records and sending the same SNI name. 


10. Operational Considerations 


When DANE is being introduced incrementally into an existing PKIX environment, there may be 
scenarios in which DANE authentication for a server fails but PKIX succeeds, or vice versa. What 
happens here depends on TLS client policy. If DANE authentication fails, the client may decide to 
fall back to regular PKIX authentication. In order to do so efficiently within the same TLS 
handshake, the TLS server needs to have provided the full X.509 certificate chain. When TLS 
servers only support DANE-EE or DANE-TA modes, they have the option to send a much smaller 
certificate chain: just the EE certificate for the former and a short certificate chain from the 
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DANE trust anchor to the EE certificate for the latter. If the TLS server supports both DANE and 
regular PKIX and wants to allow efficient PKIX fallback within the same handshake, they should 
always provide the full X.509 certificate chain. 


When a TLS server operator wishes to no longer deploy this extension, it must properly 
decommission its use. If a non-zero pin lifetime is presently advertised, it must first be changed 
to 0. The extension can be disabled once all previously advertised pin lifetimes have expired. 
Removal of TLSA records or even DNSSEC signing of the zone can be done at any time, but the 
server MUST still be able to return the associated denial-of-existence proofs to any clients that 
have unexpired pins. 


TLS clients MAY reduce the received extension pin value to a maximum set by local policy. This 
can mitigate a theoretical yet unlikely attack where a compromised TLS server is modified to 
advertise a pin value set to the maximum of 7 years. Care should be taken not to set a local 
maximum that is too short as that would reduce the downgrade attack protection that the 
extension pin offers. 


If the hosting provider intends to use end-entity TLSA records (certificate usage PKIX-EE(1) or 
DANE-EE(3)), then the simplest approach is to use the same key pair for all the certificates at a 
given hosting node and publish "1 1 1" or "3 1 1" RRs matching the common public key. Since key 
rollover cannot be simultaneous across multiple certificate updates, there will be times when 
multiple "1 1 1" (or "3 1 1") records will be required to match all the extant certificates. Multiple 
TLSA records are, in any case, needed a few TTLs before certificate updates as explained in 
Section 8 of [RFC7671]. 


If the hosting provider intends to use trust anchor TLSA records (certificate usage PKIX-TA(0) or 
DANE-TA(2)), then the same TLSA record can match all end-entity certificates issues by the 
certification authority in question and continues to work across end-entity certificate updates so 
long as the issuer certificate or public keys remain unchanged. This can be easier to implement 
at the cost of greater reliance on the security of the selected certification authority. 


The provider can, of course, publish separate TLSA records for each customer, which increases 
the number of such RRsets that need to be managed but makes each one independent of the rest. 


11. Security Considerations 


The security considerations of the normatively referenced RFCs all pertain to this extension. 
Since the server is delivering a chain of DNS records and signatures to the client, it MUST rebuild 
the chain in accordance with TTL and signature expiration of the chain components as described 
in Section 4. TLS clients need roughly accurate time in order to properly authenticate these 
signatures. This could be achieved by running a time synchronization protocol like NTP 
[RFC5905] or SNTP [RFC5905], which are already widely used today. TLS clients MUST support a 
mechanism to track and roll over the trust anchor key or be able to avail themselves of a service 
that does this, as described in Section 8. Security considerations related to mandating the use of 
this extension are described in Section 7. 
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The received DNSSEC chain could contain DNS RRs that are not related to the TLSA verification of 
the intended DNS name. If such an unrelated RR is not DNSSEC signed, it MUST be discarded. If 
the unrelated RRset is DNSSEC signed, the TLS client MAY decide to add these RRsets and their 
DNSSEC signatures to its cache. It MAY even pass this data to the local system resolver for caching 
outside the application. However, care must be taken because caching these records could be 
used for timing and caching attacks to de-anonymize the TLS client or its user. A TLS client that 
wants to present the strongest anonymity protection to their users MUST refrain from using and 
caching all unrelated RRs. 


12. IANA Considerations 


IANA has made the following assignment in the "TLS ExtensionType Values" registry: 


Value Extension Name TLS1.3 Recommended Reference 


59 dnssec chain CH No RFC 9102 
Table 1 
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Appendix A. Test Vectors 


The test vectors in this appendix are representations of the content of the "opaque 
AuthenticationChain" field in DNS presentation format and, except for the extension_data in 
Appendix A.1, do not contain the "uint16 ExtSupportLifetime" field. 


For brevity and reproducibility, all DNS zones involved with the test vectors are signed using 
keys with algorithm 13 (ECDSA Curve P-256 with SHA-256). 


To reflect operational practice, different zones in the examples are in different phases of rolling 
their signing keys: 


* All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), except for the 
example.com and example.net zones, which use a Combined Signing Key (CSK). 


* The root and org zones are rolling their ZSKs. 
* The com and org zones are rolling their KSKs. 


The test vectors are DNSSEC valid in the same period as the certificate is valid, which is between 
November 28, 2018 and December 2, 2020 with the following root trust anchor: 


IN DS ( 47005 13 2 2eb6e9f2480126691594d649a35a613de3052e37861634 
641bb568746f2ffc4d4 ) 
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The test vectors will authenticate the certificate used with https ://example.com/, https:// 
example.net/, and https://example.org/ at the time of writing: 


SE BEGIN CERTIFICATE----- 
MITHQDCCBiigAwIBAgIQD9B43Uj xor1NDyupa244/ jANBgkghkiG9w8BAOSFADBN 
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E 
aWdpQ2VydCBTSEEyIFN1Y3VyZSBTZXJ2ZXIgQOEwHhcNMTgxMTI4MDAwMDAwWhcN 
MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju 
aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm51dCBDb3Jw 
b3JhdGlvbiBmb3IgQXNzaWduZWQgTmF tZXMgYW5kIE51bWJ1cnMxEZARBgNVBAsT 
CLR1Y2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI 
hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV 
rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA6805FGGtFM1yFEaogEv5g 
rJ1MRY/d0wA-*dw8JwoV LNMci+3QTUUK f 9yH28JxEdG3J3 7Mf j 2C3cREGkGNBnY80 
eyRJRgzy8I8LSPTTkhr3okXuz0XXg38ugr1x3SgZWDNuEaE6oGpyYJIBWZ9 j F3pJ 
QnucP9vTBejMh374qvyd@QVQq3WxHrogy4nUbWw3gihMxT98wRD1oKVma1NTydvt 
heNtBfhkp8k064/hxLHrLWgOFT/14tz8IWQt7mkrBHjbd2XLVPkCAwEAAaOCA8Ew 
ggO9MB8GA1UdIwQYMBaAFA+AYRyCMWHVLy jnjUY4tCzhxtniMB@GA1UdDgQWBBRm 
mGIC4AmRp9njNvt2xrC/oW2nv jCBgQYDVR@RBHowelIPd3d3LmV4YW1wbGUub3Jn 
ggtleGFtcGx 1LmNvbYILZXhhbXBsZS51ZHWCC2V4YW1wbGUubmVaggt leGFtcGx1 
Lm9yZAIPd3d3LmV4YW1wbGUuY29tgg93d3cuZXhhbXBsZS51ZHWCD3d3dy5leGFt 
cGx1Lm51dDAOBgNVHQ8BAf 8EBAMCBaAwHQYDVRO1BBYwF AY IKwYBBQUHAWEGCCSG 
AQUFBwMCMGsGA1UdHwRkMGIwL6AtoCuGKWh@dHA6L y9 j cmwzLmRpZ21 j ZXJOL mNv 
bS9zc2NhLXNoYTItZzYuY3JsMC*gLaArhilodHRwOi8vY3JsNC5kaWdpY2VydC5j 
b20vc3Nj YS1zaGEyLWc2LmNybDBMBgNVHSAERTBDMDcCGCWCGSAGG /WWBATAqMCgG 
CCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5 jb20vQ1BTMAgGBmeBDAEC 
AjB8BggrBgEFBQcBAQRwMGA4wJAYIKwYBBQUHMAGGGGhOdHA6L y9 v Y3NwLmRpZ21 j 
ZXJOLmNvbTBGBggrBgEFBQcwAoY6aHROcDovL2NhY2VydHMuZGlnaWNlcnQuY29t 
LORpZ21DZXJOUOhBMINIlY3VyZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EA j AAMIIB 
fwYKKwYBBAHWeQIEAgSCAW8EggF r AWkAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb 
37 j jd880yA3cEAAAAWdcMZVGAAAEAwBIMEYCIOCEZIG3IR36Gk j 1dg5L6EaGVycX 
sHvp07dKV8JSsooTEbAIhALUTt f4wxGTkFkx8b 1hTV+7sf6pFT780Ro07+cP39 jk JC 
AHYAh3W/5118+IxDmV+9827/Vo1HV jb/SrVgwbTq/16ggw8AAAFnXDGWFQAABAMA 
RzBFAiBvqnfSHKeUwGMtL r0G3UGLQIoaL3-*uZsGTX3Mf SJNQEQIhANL5nUiGBR6g 
leQlCzzqzvorGXyB/yd7nttYttzo8bEpOAHYAb1N2 rDHwMRnYmQCKkURX / dXUcEdkC 
wQApBo2yCJo32RMAAAFnXDGWnAAABAMARZzBF AiEA5Hn7QA4SOyqHkT-*kDsHq7ku7z 
RDuM7PAUDX2ft2MpnyOCIE13WtxJAUrOaASFYZ/XjSAMMfrBO/RxC1lvWVss9OLHKM 
MAOGCSqGSIb3DQEBCwUAAAIBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLePAR 
8CmgDM1pFAvGBHiyzvCH1QGdxF16cf7wbp7BoLCRLR/qPVXFMwUMzCcE 1GLBqaGZM 
v1Yh21vZSLmMNSGRXdx113pGLCInpm/TOhf rvr@TxRImc8BdozWJavsn1N2qdHQu 
N+UBO6bQMLCD@KHEdSGF suX6ZwAworxTg82/1giDu7zW7RyzHvFYA4IAjpzvkPIa 
X6KjBtpdvp/aXabmL95YgBj T8WJ7pqOf rqhpcm0BZa6Cg60114qbIFH/Gj9hQB5I 
@Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN 

3738 END CERTIFICATE----- 
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A.1. „443. tcp.www.example.com 
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-443. tcp.www.example.com. 3600 IN TLSA (311 


8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 
922 ) 


-443. tcp.www.example.com. 3688 IN RRSIG ( TLSA 13 5 3600 


20201202000000 20181128000000 1870 example.com. 
rqY69NnTfACN3GBGQjKEJCLAMsRKUrXe0JW8IqDb5rQHHzxNqqPeEoi-*2vl6S 
z2BhaswpGLVVuoi juVdzxY jmw== 


example.com. 3600 IN DNSKEY ( 257 3 13 


JnA1XgyJTZz*psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 
/TsSfZMaGW vlsuieh5nHcXzA-- ; Key ID - 1870 


example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 


20201202000000 20181128000000 1870 example.com. 
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN@MS8Gjtli9NVRYeSIzt 
QHPGSpvRxTUC4tZi62z1UgGDw== ) 


example.com. 172888 IN DS ( 1878 13 2 e9b533a049798e900b5c29c90cd 


25a986e8a44f319ac3cd302bafc08f5b81e16) 


example.com. 172888 IN RRSIG ( DS 13 2 172800 


com. 


com. 


com. 


com. 


com. 


com. 


com. 


com. 


20201202000000 20181128000000 34327 com. 
SEAKvX4H6pJfN8nKcclB1NRcRSPOztx80omr4fCSHu61p-*uESP /Le4iF2sKukO 
J1hhWSB6 j gubEV117rGNOA/YQ-- 

172800 IN DNSKEY ( 256 3 13 
7IIE5Do18jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCW;j 
3URIZ8LS3Fa2gBLMOZUzZ1GQCw-- ; Key ID = 34327 

172800 IN DNSKEY ( 257 3 13 
Rbkc0+96XZmnp8jYIuM41ryAp3eg0jSmBaSoiA7H76Tm8RLHPNPUx1Vk+n08f 
Ic318xfZDNw8Wa0Pe3/g2QA/w-- ) ; Key ID = 18931 

172888 IN DNSKEY ( 257 3 13 
szc7biLo5J40Hlkan1vZrF4aD4YYf+NHA /GAgdNs1Y9xxK91zg68XHkgck4Rt 
DiVk371NAQmgSlHbrGuOyOTkA-- ) ; Key ID = 28809 

172888 IN RRSIG ( DNSKEY 13 1 172888 20201202000000 
20181128000000 18931 com. 
LJAp5ORS2VilLlwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V-*Z0yA5 
7LFdPKpcvb8BvhM+GgKWGBEsg== ) 

172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 28809 com. 
s0+4X2N21 yS6x8+dBVBZbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLk17Ev 
mDXqz6KEhhQj T-aQWDt6WFHlA-- ) 

86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 
f9eabb94487e658c188e7bcb52115 ) 

86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 
70643bbde681db342a9e5cf2bb380 ) 

86400 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 . 

NDiDIBjXEE/6AudhC++Hui1ckPcuAnGb jEASNoxA3ZHj1XRzL858UzePko5Pb 
vBKTf6pk8JRCqnfz102QY-4WXA-- 
86400 IN DNSKEY ( 256 3 13 
ZKz*DCWkNA / vuheiVPcGqsHA0U8A4KZAlrMRIyozj9WHzf8PsFp/oR8j8vmj jW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 

86488 IN DNSKEY ( 256 3 13 
8wMZZ41zHdyKZ4fv8kys/t30M1gvEadbsbygWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ) ; Key ID = 2635 

86488 IN DNSKEY ( 257 3 13 
yvX*VNTUjxZiGvtr060hVbrPV9H6rVusQtF91lIxCFzbZOJxMQBFmbqlc8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ; Key ID - 47005 

86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 
20181128000000 47005 
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OEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- 
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A hex dump of the extension data ofthe server's dnssec chain extension representation of 
this with an ExtSupportLifetime value of 0 is: 
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RFC 9102 
0000: 88 
0010: 87 
0020: 01 
0030: 7f 
0040: c5 
0050: 5f 
0060: 03 
0070: 34 
0080: 4e 
0090: 3a 
0030: 9c 
00b0: 5f 
Baca: 79 
Bada: 78 
00e0: 088 
00f0: 9c 
8188: 12 
8118: ce 
0120: 5b 
8138: 65 
0140: 88 
0150: 07 
0160: 28 
0170: Od 
0180: c4 
0190: 9c 
01a0: 65 
01b0: 88 
01c0: Ge 
0140: 3c 
01e0: 6c 
01f0: 57 
0200: 88 
0210: 13 
0220: 81 
0230: 58 
0240: 52 
0250: 81 
0260: 25 
0270: c2 
0280: f2 
0290: b6 
02a0: 088 
02b0: 1c 
02c0: a7 
02d0: 12 
02e0: 5f 
02f0: 6f 
0300: Bd 
0310: ac 
0320: sf 
0330: 95 
0340: 90 
0350: 00 
0360: 49 
0370: c9 
0380: 3f 
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04 
78 
00 
ff 
34 
63 
6f 
05 
65 
b7 
ae 
af 
74 
6d 
10 
a6 
24 
71 
89 
63 
Gd 
07 
30 
la 
d7 
2a 
61 
a3 
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_25._tcp.example.com. 3600 IN TLSA (311 
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 
922 ) 

-25. tcp.example.com. 3688 IN RRSIG ( TLSA 13 3 3600 
20201202000000 20181128000000 1870 example.com. 
BZawXvte5SyF8hnXviKDWg115E2v+RMXgaSE+NOcAM1ZOrSMUkfyPgvkv53K2 
rfL4DFP8r03VMgIOvtogroxðw== 

*. tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG 
NSEC TLSA ) 

*. tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 
20201202000000 20181128000000 1870 example.com. 

K6u8KrR8ca5bj tbce3w8y jMXr9vw122251AwyIHpxptY430MLCUCenwpYW5gd 
mpFvAacgj4+tSkKiN279SI9pA== 

example.com. 3688 IN DNSKEY ( 257 3 13 
JnA1XgyJTZz*psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 
/TsSfZMaGW/vlsuieh5nHcXzA-- ) ; Key ID = 1870 

example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 
20201202000000 20181128000000 1870 example.com. 
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoNOMS8Gjtli9NVRYeSIzt 
QHPGSpvRxTUC4tZi62z1UgGDw== ) 

example.com. 172888 IN DS ( 1878 13 2 e9b533a049798e900b5c29c90cd 
25a986e8a44f319ac3cd302bafc08f5b81e16 ) 

example.com. 172888 IN RRSIG ( DS 13 2 172800 
20201202000000 20181128000000 34327 com. 
SEAKvX4H6pJfN8nKcc1B1NRcRSPOzZtx8omr4 fCSHu6lp+uESP/Le4iF2sKukO 
J1hhWSB6 j gubEV117rGNOA/YQ-- 

com. 17280@ IN DNSKEY ( 256 3 13 
7IIE5Do18jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCW;j 
3URIZ8LS3Fa2gBLMOZUzZ1GQCw-- ; Key ID = 34327 

com. 172888 IN DNSKEY ( 257 3 13 
Rbkc0+96XZmnp8jYIuM41ryAp3eg0jSmBaSoiA7H76Tm8RLHPNPUx1Vk+n08f 
Ic318xfZDNw8WaaPe3 /g2QA/w== ; Key ID = 18931 

com. 172888 IN DNSKEY ( 257 3 13 
szc7biLo5J40Hlkan1vZrF4aD4YYf+NHA /GAqdNs1Y9xxK9Izg68XHkqck4Rt 
DiVk371NAQmgS1HbrGu@yOTkA== ; Key ID = 28809 

com. 172888 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 18931 com. 
LJAp5ORS2VilLwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr 1V-*Z0yA5 
7LFdPKpcvb8BvhM+GqKWGBEsg== ) 

com. 172888 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 28809 com. 
s0+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6 JaB1gDOCS5LLk17Ev 
mDXqz6KEhhQj T-aQWDt6WFHlA-- ) 

com. 86488 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 
f9eabb94487e658c188e7bcb52115 ) 

com. 86488 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 
70643bbde681db342a9e5cf2bb380 ) 

com. 86488 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 
NDiDIBjXEE/6AudhC++Hui1ckPcuAnGb jEASNoxA3ZHj1XRzL858UzePko5Pb 
vBKTf6pk8JRCqnfz102QY-4WXA-- 

86400 IN DNSKEY ( 256 3 13 
ZKz*DCWkNA / vuheiVPcGqsHA0U8A4KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 

86488 IN DNSKEY ( 256 3 13 
8wMZZ41zHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ; Key ID - 2635 
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86488 IN DNSKEY ( 257 3 13 
yvX*VNTUjxZiGvtr060hVbrPV9H6rVusQtF91lIxCFzbZOJxMQBFmbqlc8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ; Key ID - 47005 

86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 
20181128000000 47005 . 
OEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- ) 
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_25._tcp.example.org. 3600 IN TLSA (311 


8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 
922 ) 


-25. tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 


20201202000000 20181128000000 56566 example.org. 
lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0 jxtDyEP818Q1RA1L 
cYzJ7vCvqb9gFCiCJjK2gAamw-- 


dlm7rss9pejqnh0ev6h7k1likqqcl5mae.example.org. 3608 IN NSEC3 ( 


101 - t6lf7uuoiO0qofq0nvdjroavo46pp20im RRSIG TLSA ) 


dlm7rss9pejqnh@ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( 


NSEC3 13 3 3600 20201202000000 20181128000000 56566 
example.org. 
guUyy9LIZIlYbOFZttAdYJGrFNKpKu91Tm*dPOz98rnpwIlwwvLifXIvIl190nE 
X38cWzEQOpreJu3t4WAfPsxdg-- ) 


example.org. 3600 IN DNSKEY ( 256 3 13 


NrbL6utGgIW1wrhhjeexdA6bMdD11C1hj8Fnpevaa1AMyY2uy83TmoGnR996N 
UR5T1G4Zh+YPbbmUIixe4nS3w== ; Key ID = 56566 


example.org. 3688 IN DNSKEY ( 257 3 13 


uspaqp17jsMTX6AWVgmbog/3Sttz-*9ANFUWLn6qKUHrOBOqRuChQWj8 j y YUUr 
Wy9txxesNQ9MkOALUrFght1LQ-- ; Key ID - 44384 


example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 


20201202000000 20181128000000 44384 example.org. 
ttse9pYp9PSu@pJ+TOpIVFLWJ6NKOMWZX4Q/S1U6Z faikQc@Bg7Tut9+wPunk 
60PPvyHjVXMAsvk@tqV@B+/ag== 


example.org. 86488 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51 


3c8003e1d9121f1ff11a08b4cdd348d090aa6 ) 


example.org. 86488 IN RRSIG ( DS 13 2 86400 20201202000000 


org. 


org. 


org. 


org. 


org. 


org. 


org. 


org. 


org. 


20181128000000 9523 org. 
m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62 
clpAfvZHx59Ackst4X+zXYpUA== ) 

86400 IN DNSKEY ( 256 3 13 
fuLp6OznhSSEr9HowILpTpyLKQdM6ixcgkTEO0gqVdsLx4-DSNHSc6906fLWCOe 
HfWx7kzlBBoJBOvLrvsJtXJ6g-- ; Key ID - 47417 

86400 IN DNSKEY ( 256 3 13 
zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5Rj Vix9YH6+iwpBXb6qfHyQHy 
m1MiAAoaoXh7BUkEBVgDVN8sQ-- ; Key ID = 9523 

86400 IN DNSKEY ( 257 3 13 
Uf24EyNt51DMcLV+dHPInhSpmjPngAONUTouU+SGLu+1FRR1Betgw1bJUZNI6 
Diger@VJTm@QuX/JVXcyGVGoQ== ) ; Key ID = 49352 

86400 IN DNSKEY ( 257 3 13 
8SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doN1gc31ddcM1MbTvJ 
HTjK6Fvy8W6yZ+cAptn8s0heg== ) ; Key ID = 12651 

86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 
20181128000000 12651 org. 
Gq9wf-*z3pasXXUwE210 j YcOLhJnMAhcwXydnvkHtCVY6 /0jUafHOA4RksN84Zt 
us@pUgWngbT /OWXskdMYXZU4A== ) 

86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 
20181128000000 49352 org. 
VGEKEMWBJ2IbO0pm2Z560xu2NGPcVUDWCbYRyk+0k1+HzGtyd2gPEKkpgMs/8p 
vZEMj1YXD+dIgb2nUK9PGBAXw== ) 

86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 
9db5c24a75743eb1e704b97a9fabc ) 

86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3cOffO0db765fe 
f4a2f18920db5f58710dd767c293b ) 

86400 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 . 
adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcM jdCD3pyonWO5JPRV 
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EemgaE357S4pX5D8tVZzeZJ6A== 

86488 IN DNSKEY ( 256 3 13 
zZKzZ+DCWkNA/vuheiVPcGgsH48U84KZALrMRIy0z j9WHzf8PsFp/oR8j8vmj jW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 

86488 IN DNSKEY ( 256 3 13 
8wMZZ41zHdyKZ4fv8kys/t30M1gvEadbsbygWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ; Key ID - 2635 

86400 IN DNSKEY ( 257 3 13 
yvX*VNTUj xZiGvtr060hVbrPV9H6rVusQtF91IxCFzbZOJxMQBFmbqlc8Xclv 
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 

86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 
20181128000000 47005 
QEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- 


Dukhovni, et al. Experimental Page 30 


RFC 9102 TLS DNSSEC Chain August 2021 


A.A. „443. tcp.www.example.org CNAME 


Dukhovni, et al. Experimental Page 31 


RFC 9102 


TLS DNSSEC Chain 


-443. tcp.www.example.org. 3600 IN CNAME ( 


dane311.example.org. ) 


-443. tcp.www.example.org. 3688 IN RRSIG ( CNAME 13 5 3600 


20201202000000 20181128000000 56566 example.org. 
RedUe6Rt4G-*2ablrQH9Zw8j INHBLMgNYTI5+H7nO8SNZ5Nm8wONZr Xv3Qp7gx 
Qb/a900696120NsYaZX2*ebBA-- ) 


dane311.example.org. 3688 IN TLSA (311 


8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 
922 ) 


dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 


20201202000000 20181128000000 56566 example.org. 
f6TbTZTpu3h6MYpLkKQwWILAKYQ3EUY-Nsoa6any6yt-aeuunMU jw-*IJB2QLm 
0x0PrD7m39JA3NUSKUp9riNNQ-- ) 


example.org. 3600 IN DNSKEY ( 256 3 13 


NrbL6utGgIW1wrhhjeexdA6bMdD11C1hj8Fnpevaa1AMyY2uy83TmoGnR996N 
URBTIGAZh*YPbbmUIixe4nS3w-- ) ; Key ID = 56566 


example.org. 3600 IN DNSKEY ( 257 3 13 


uspagp17j sMTX6AWVgmbog/3Sttz+9ANFUWLn6gKUHr8BOgRuCchaWj8jyYUUr 
Wy9txxesNQ9MkOALUrFght1LQ-- ; Key ID - 44384 


example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 


20201202000000 20181128000000 44384 example.org. 
ttse9pYp9PSu@pJ+TOpIVFLWJ6NKOMWZX4Q/S1U6Z faikKQc@Bg7Tut9+wPunk 
60PPvyHjVXMAsvk@tqV@B+/ag== 


example.org. 86488 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51 


3c8003e1d9121f1ff11a08b4cdd348d090aa6 ) 


example.org. 86488 IN RRSIG ( DS 13 2 86400 20201202000000 


org. 


org. 


org. 


org. 


org. 


org. 


org. 


org. 


org. 


20181128000000 9523 org. 
m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62 
clpAfvZHx59Ackst4X+zXYpUA== ) 

86400 IN DNSKEY ( 256 3 13 
fuLp6OznhSSEr9HowILpTpyLKQdM6ixcgkTEO0gqVdsLx4-DSNHSc6906fLWCOe 
HfWx7kzlBBoJBOvLrvsJtXJ6g-- ; Key ID - 47417 

86400 IN DNSKEY ( 256 3 13 
zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5Rj Vix9YH6+iwpBXb6qfHyQHy 
m1MiAAoaoXh7BUkEBVgDVN8sQ-- ; Key ID = 9523 

86400 IN DNSKEY ( 257 3 13 
Uf24EyNt51DMcLV+dHPINhSpmjPngAONUTouU+SGLu+1FRR1Betgw1bJUZNI6 
Dlger@VJTm@QuX/JVXcyGVGoQ== ) ; Key ID = 49352 

86488 IN DNSKEY ( 257 3 13 
8SZfoe8Yx+eoaGgyAGEeJax/ZBV1AUuG+/smcOgRm+F6doN1gc31ddcM1MbTvJ 
HTjK6Fvy8W6yZ*cAptn8sQheg-- ) ; Key ID = 12651 

86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 
20181128000000 12651 org. 
Gq9wf-*z3pasXXUwE210 j YcOLhJnMAhcwXydnvkHtCVY6 /0jUafHOA4RksN84Zt 
us@pUgWngbT /OWXskdMYXZU4A== ) 

86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 
20181128000000 49352 org. 
VGEKEMWBJ2IbO0pm2Z560xu2NGPcVUDWCbYRyk+0k1+HzGtyd2gPEKkpgMs/8p 
vZEMj1YXD+dIgb2nUK9PGBAXw== ) 

86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 
9db5c24a75743eb1e704b97a9fabc ) 

86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3cOffO0db765fe 
f4a2f18920db5f58710dd767c293b ) 

86400 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 . 
adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcM jdCD3pyonWO5JPRV 
EemgaE357S4pX5D8tVZzeZJ6A== 


Dukhovni, et al. Experimental 


August 2021 


Page 32 


RFC 9102 TLS DNSSEC Chain August 2021 


86400 IN DNSKEY ( 256 3 13 
zZKzZ+DCWkNA/vuheiVPcGgsH48U84KZALrMRIy0z j9WHzf8PsFp/oR8j8vmj jW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 

86488 IN DNSKEY ( 256 3 13 
8wMZZ41zHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ; Key ID - 2635 

86400 IN DNSKEY ( 257 3 13 
yvX*VNTUj xZiGvtr060hVbrPV9H6rVusQtF91IxCFzbZOJxMQBFmbqlc8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ; Key ID - 47005 

86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 
20181128000000 47005 
GEPW1ca+N/ZhZPKla77STG734cTeI0jUwg7eW8HsnOofudWmnCEVeco2wLLg9m 
nBT1dtNjIczvLG9pQTnOKUsHQ== 
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example.net. 3600 IN DNAME example.com. 
example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000 


20181128000000 48885 example.net. 
o3uV5k5Ewp5fdr0Zt@n4QuH+/Hpku2Lo3CzGRt9 /MS2zZt2Qb/AXz43 5UFQBx 
OI/pDnjJcLSd/gBLtqR52WLMA-- ) 


-443. tcp.www.example.net. 3600 IN CNAME ( 


-443. tcp.www.example.com. 


_ 443. tep.www.example .com. 3688 IN TLSA (311 


8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 
922 ) 


-443. tcp.www.example.com. 3688 IN RRSIG ( TLSA 13 5 3600 


20201202000000 20181128000000 1870 example.com. 
rqY69NnTfACN3GBGQjKEJCLAMSRKUrXe0JW8IqDb5rQHHzxNqqPeEoi-*2vl6S 
z2BhaswpGLVVuoijuVdzxYjmw-- ) 


example.net. 3688 IN DNSKEY ( 257 3 13 


X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp-*5cTJk7qDazwH68Kts8d 
9MvN55HddWgsmeRhgzePz6hMg-- ) ; Key ID = 48085 


example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600 


20201202000000 20181128000000 48085 example.net. 
CkwqgEt1p970Ma3w5LctIjKIuG5XVSapKrfwuHhb5p04fWXRMNsXasG / kd2F / 
wlmMWiq38gO0QaYCLNm*cjQzpQ-- ) 


example.net. 172888 IN DS ( 48085 13 2 7c1998ce683df60e2fa41460c4 


53f88f463dac8cd5d074277b4a7c04502921be ) 


example.net. 172800 IN RRSIG ( DS 13 2 172800 


net. 


net. 


net" 


nee: 


net. 


exa 


20201202000000 20181128000000 10713 net. 
w@JxDeiBJZN1pCdxKtRENlqfTpSxcs6Vftscsyfo/hyeTPYcIt4yItDkYsYK+ 
KQ6FYAVEAnisA3vDQoZVL4wow-- 
172800 IN DNSKEY ( 256 3 13 
061EoQsAsBcDsPiz17vt4nFSGLmXAGguqLStOesmKNCimiA4/1lw/vtyfqALuLF 
JiFjtCK3HMPi8HQ1jbGEwbGCA-- ; Key ID = 10713 
172800 IN DNSKEY ( 257 3 13 
LkNCPE-*v3SAMVnsOqZFhn8n2NSwtLYOZLZ j j gVsAKgu4XZncaDgq1R/7ZXRO5 
oVx2zthxuu2i+mGbRrycAaCvA== ; Key ID = 485 
172888 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 485 net. 
031jXg06zSuDwI5zqYuYFJg105p*zy85csMXagvRxB9W21L /WJRi6Gn9BcaCV 
RnDId5WR+yCADhsbKfSrrd9vQ== ) 
86400 IN DS ( 485 13 2 ab25a2941aa7f1eb8688bb783b25587515a0c 
d8c247769b23adb13ca234d1c05 ) 
86488 IN RRSIG ( DS 13 1 86408 20201202000000 
20181128000000 31918 
vOXoT jxggGTYKIwssQ3kpML@ag6D@Hcm+Syy7++4zT7gaFHfRH9a6uZekIWdb 
oss8y/7q4onW4rxKdtw2S28hwQ== 
86400 IN DNSKEY ( 256 3 13 
ZKz+DCWkNA/vuheiVPcGqsH40U84KZA1rMRIyoz j9WHzf8PsFp/oR8j8vmj jW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 

86488 IN DNSKEY ( 256 3 13 
8wMZZ41zHdyKZ4fv8kys/t30M1gvEadbsbygWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ) ; Key ID = 2635 

86400 IN DNSKEY ( 257 3 13 
yvX*VNTUjxZiGvtr060hVbrPV9H6rVusQtF91lIxCFzbZOJxMQBFmbqlc8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ) ; Key ID = 47005 

86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 
20181128000000 47005 
OEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- 

mple.com. 3688 IN DNSKEY ( 257 3 13 
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JnA1XgyJTZz*psWvbrfUWLV6eULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 
/TsSfZMaGW/vlsuieh5nHcXzA-- ) ; Key ID = 1870 


example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 


20201202000000 20181128000000 1870 example.com. 
nYisnu/26Sw1 qmGuREa9o/fLgYuA4oNPt4+6PMBZoNO@MS8Gjtli9NVRYeSIzt 
QHPGSpvRxTUC4tZi62z1UgGDw== ) 


example.com. 172888 IN DS ( 1878 13 2 e9b533a049798e900b5c29c90cd 


25a986e8a44f319ac3cd302bafc08f5b81e16 ) 


example.com. 172888 IN RRSIG ( DS 13 2 172800 


20201202000000 20181128000000 34327 com. 
SEAKvX4H6pJfN8nKcclB1NRcRSPOztx80omr4fCSHu61p-*uESP /Le4iF2sKukO 
J1hhWSB6 j gubEV117rGNOA/YQ-- 


com. 172888 IN DNSKEY ( 256 3 13 
7IIE5Do18jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCW;j 
3URIZ8LS3Fa2gBLMOZUzZ1GQCw-- ; Key ID = 34327 

com. 172888 IN DNSKEY ( 257 3 13 
Rbkc0+96XZmnp8jYIuM41ryAp3eg0jSmBaSoiA7H76Tm8RLHPNPUx1Vk+n08f 
Ic318xfZDNw8WaaPe3 /g2QA/w== ; Key ID = 18931 

com. 172888 IN DNSKEY ( 257 3 13 
szc7biLo5JA40HlkanivZrFAaDAYYf*NHA/GAqdNs1Y9xxK9Izg68XHkqckA4Rt 
DiVk371NAQmgS1HbrGu@yOTkA== ; Key ID = 28809 

com. 172888 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 18931 com. 
LJ4p50RS2VilLwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V-ZOyA5 
7LFdPKpcvb8BvhM+GgKWGBE sg== ) 

com. 172888 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 28809 com. 
s0+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6 JaB1gDOCS5LLk17Ev 
mDXqz6KEhhQj T-aQWDt6WFHlA-- ) 

com. 86488 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 
f9eabb94487e658c188e7bcb52115 ) 

com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 
70643bbde681db342a9e5cf2bb380 ) 

com. 86488 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 
nDiD1BjXEE/6AudhC++HuilckPcuAnGb jEASNoxA3ZHj1XRzL858UzePko5Pb 
vBKTf6pk8JRCqnfz102QY-4WXA-- 

Dukhovni, et al. Experimental 


August 2021 


Page 36 


RFC 9102 TLS DNSSEC Chain August 2021 


Ap „25. tcp.smtp.example.com NSEC Denial of Existence 


Dukhovni, et al. Experimental Page 37 


RFC 9102 TLS DNSSEC Chain 


smt 


smt 


exa 


exa 


exa 


exa 


com. 


com. 


com. 


com. 


com. 


com. 


com. 


com. 


p.example.com. 3600 IN NSEC ( www.example.com. A AAAA 
RRSIG NSEC ) 
p.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 
20201202000000 20181128000000 1870 example.com. 
rH/K4wghCOm4 j pEHwQKiyZzvFIa7qpFySuKIGGetWASEA402Mh5j PxcEz f 78Hf 
crlsQZmnAUlfmBNCygxAd7JNw-- ) 
mple.com. 3600 IN DNSKEY ( 257 3 13 
JnA1XgyJTZz*psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 
/TsSfZMaGWvv1suieh5nHcXzZA== ; Key ID = 1870 

mple.com. 3688 IN RRSIG ( DNSKEY 13 2 3688 
20201202000000 20181128000000 1870 example.com. 
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoNOMS8Gjtli9NVRYeSIzt 
QHPGSpvRxTUC4tZi62z1UgGDw== ) 

mple.com. 172888 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd 

25a986e8a44f319ac3cd302bafc08f5b81e16 ) 
mple.com. 172888 IN RRSIG ( DS 13 2 172800 
20201202000000 20181128000000 34327 com. 
SEAKvX4H6pJfN8nKcclB1NRcRSPOztx80omr4fCSHu61p-*uESP/Le4iF2sKukO 
J1hhWSB6 j gubEV117rGNOA/YQ-- 
172800 IN DNSKEY ( 256 3 13 
7IIE5Do18jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCW;j 
3URIZ8LS3Fa2gBLMOZUzZ1GQCw-- ; Key ID = 34327 
172800 IN DNSKEY ( 257 3 13 
Rbkc0+96XZmnp8jYIuM41ryAp3eg0jSmBaSoiA7H76Tm8RLHPNPUx1Vk+n08f 
Ic318xfZDNw8Wa@Pe3/g2QA/w== ) ; Key ID = 18931 
172888 IN DNSKEY ( 257 3 13 
szc7biLo5J40Hlkan1vZrF4aD4YYf+NHA /GAgdNs1Y9xxK91zg68XHkgck4Rt 
DiVk371NAQmgSlHbrGuOyOTkA-- ) ; Key ID = 28809 
172888 IN RRSIG ( DNSKEY 13 1 172888 20201202000000 
20181128000000 18931 com. 
LJAp5ORS2VilLwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V-*Z0yA5 
7LFdPKpcvb8BvhM+GgKWGBEsg== ) 
172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 
20181128000000 28809 com. 
s0+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6 JaB1gDOCS5LLk17Ev 
mDXqz6KEhhQj T-aQWDt6WFHlA-- ) 
86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 
f9eabb94487e658c188e7bcb52115 ) 
86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 
70643bbde681db342a9e5cf2bb380 ) 
86400 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 
NDiDIBjXEE/6AudhC++Hui1ckPcuAnGb jEASNoxA3ZHj1XRzL858UzePko5Pb 
vBKTf6pk8JRCqnfz102QY-4WXA-- 
86400 IN DNSKEY ( 256 3 13 
ZKz*DCWKkNA / vuheiVPcGqsHA0U8A4KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 

86488 IN DNSKEY ( 256 3 13 
8wMZZ41zHdyKZ4fv8kys/t30M1gvEadbsbygWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ) ; Key ID = 2635 

86488 IN DNSKEY ( 257 3 13 
yvX*VNTUjxZiGvtr060hVbrPV9H6rVusQtF91lIxCFzbZOJxMQBFmbqlc8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ) ; Key ID = 47005 

86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 
20181128000000 47005 . 
QEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- 
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vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN NSEC3 ( 
1 0 1 - 93u63bg57ppj6649a12n31192iedkjd6 A AAAA RRSIG ) 

vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG ( 
NSEC3 13 3 3600 20201202000000 20181128000000 56566 
example.org. 
wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUy j KQksh 
gQeV5KgP1cdvPt1BEowKqK4Sw-- 

dlm7rss9pejqnh@ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( 
101 - t6lf7uuoiO0qofq0nvdjroavo46pp20im RRSIG TLSA ) 

dlm7rss9pejqnh0ev6h7k1likqqcl5mae.example.org. 3600 IN RRSIG ( 
NSEC3 13 3 3600 20201202000000 20181128000000 56566 
example.org. 
guUyy9LIZIlYbOFZttAdYJGrFNKpKu91Tm*dPOz98rnpwIlwwvLifXIvIl190nE 
X38cWzEQOpreJu3t4WAfPsxdg-- ) 

a73bi8coh6dvflarqdeuogf95r0828mk.example.org. 3600 IN NSEC3 ( 
101 - cip01p71118gdn0j113pp1o41h35untj CNAME RRSIG ) 

a73bi8coh6dvflarqdeuogf95r0828mk.example.org. 3600 IN RRSIG ( 
NSEC3 13 3 3600 20201202000000 20181128000000 56566 
example.org. 
ePBUuMd j 8Bc+/41gHBm2Bx/IK/j /04W7AS5uTgSj /0Sd57mP /NTWRZq3p8yBNe 
FPC2mBJ20WQFi6/V9dmyiBh2A== ) 

example.org. 3600 IN DNSKEY ( 256 3 13 
NrbL6utGqliIW1wrhhjeexdA6bMdD11C1hjOFnpevaa1AMyY2uy83TmoGnR996N 
UR5T1G4Zh+YPbbmUIixe4nS3w== ; Key ID = 56566 

example.org. 3688 IN DNSKEY ( 257 3 13 
uspaqp17jsMTX6AWVgmbog/3Sttz-*9ANFUWLn6qKUHrOBOqRuChQWj8 j y YUUr 
Wy9txxesNQ9MkOALUrFght1LQ-- ; Key ID - 44384 

example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 
20201202000000 20181128000000 44384 example.org. 
ttse9pYp9PSu@pJ+TOpIVFLWJ6NKOMWZX4Q/S1U6Z faikQc@Bg7Tut9+wPunk 
60PPvyHj VXMAsvk@tqV@B+/ag== 

example.org. 86488 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51 
3c8003e1d9121f1ff11a08b4cdd348d090aa6 ) 

example.org. 86488 IN RRSIG ( DS 13 2 86400 20201202000000 
20181128000000 9523 org. 
m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62 
clpAfvZHx59Ackst4X+zXYpUA== ) 

org. 86488 IN DNSKEY ( 256 3 13 
fuLp6OznhSSEr9HowILpTpyLKQdM6ixcgkTEO0gqVdsLx4-DSNHSc6906fLWCOe 
HfWx7kzlBBoJBOvLrvsJtXJ6g-- ; Key ID - 47417 

org. 86488 IN DNSKEY ( 256 3 13 
zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5Rj Vix9YH6+iwpBXb6qfHyQHy 
m1MiAAoaoXh7BUkEBVgDVN8sQ-- ; Key ID = 9523 

org. 86488 IN DNSKEY ( 257 3 13 
Uf24EyNt51DMcLV+dHPInhSpmjPngAONUTouU+SGLu+1FRR1Betgw1bJUZNI6 
Dlger@VJTm@QuX/JVXcyGVGoQ== ) ; Key ID = 49352 

org. 86488 IN DNSKEY ( 257 3 13 
8SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doN1gc31ddcM1MbTvJ 
HTjK6Fvy8W6yZ+cAptn8s0heg== ) ; Key ID = 12651 

org. 86488 IN RRSIG ( DNSKEY 13 1 86488 20201202000000 
20181128000000 12651 org. 
Gg9wf+z3pasXXUwE218jYc8LhJNMAhcwXydnvkHtCvY6/8jUafHO4RkSN84Zt 
us@pUgWngbT /OWXskdMYXZU4A== ) 

org. 86488 IN RRSIG ( DNSKEY 13 1 86488 20201202000000 
20181128000000 49352 org. 
VGEKEMWBJ2IbO0pm2Z560xu2NGPcVUDWCbYRyk+0k1+HzGtyd2gPEKkpgMs/8p 
vZEMj1YXD+dIgb2nUK9PGBAXw== 
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86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 
9db5c24a75743eb1e704b97a9fabc ) 

86400 IN DS ( 49352 13 2 03d11alaa114abbb8f788c3caffadb765fe 
f4a2f18920db5f58710dd767c293b ) 

86400 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 . 
adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcM jdCD3pyonWO5JPRV 
EemgaE357S4pX5DOtVZzeZJ6A-- ) 


86400 IN DNSKEY ( 256 3 13 


ZKz*DCWkNA /vuheiVPcGqsHA0U8A4KZAlrMRIyozj9WHzf8PsFp/oR8j8vmj jW 
P98cbte4d8NvlGLxzbUzo3*FA-- ) ; Key ID = 31918 


86400 IN DNSKEY ( 256 3 13 


8wMZZ41zHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ; Key ID - 2635 


86400 IN DNSKEY ( 257 3 13 


yvX*VNTUjxZiGvtr060hVbrPV9H6rVusQtF91lIxCFzbZOJxMQBFmbqlc8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ; Key ID - 47005 


86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 


20181128000000 47005 
OEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- 
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A.8. „443. tep.www.insecure. example NSEC3 Opt-Out Insecure Delegation 


c1kgc91hrn9ngi2gjh1ms78ki8p7s750.example. 43208 IN NSEC3 


1 1 1 - shn@5itmoa45mmnv741c4p@nnfmimtjt NS SOA RRSIG DNSKEY 
NSEC3PARAM ) 


c1kgc91hrn9ngi2gjh1ms78ki8p7s750.example. 43288 IN RRSIG ( 


NSEC3 13 2 43200 20201202000000 20181128000000 15903 

example. 

pW16gQOLhLpKYgXpGt4XB4092W/QoPYyG5C jQ-*t-*g7LBVcCiPQv8ars1j9UOg 
RpXUsJhZBDax2dfDhK7zOk70w-- ) 


shn85itmoa45mmnv741c4põnnfmimtjt.example. 43288 IN NSEC3 ( 


1 1 1 - a3ibldvf1bdtfmd91usrdemsfiiepi6p NS DS RRSIG ) 


shn85itmoa45mmnv741c4põnnfmimtjt.example. 43288 IN RRSIG ( 


example. 


example. 


example. 


example. 


NSEC3 13 2 43200 20201202000000 20181128000000 15903 
example. 
5Aq/ / ABbsWNwcXbT91pMX20qf 8VpJQR j qHAD2yZE1W00wKmt 85mhgu2qYPr vH 
QwGEB4STMz2Nefq@1 /GY6NHKg== 

432000 IN DNSKEY ( 257 3 13 
yrkqXSbVwXOoUxC j r /E9yg8XUzbZN1wP11VsoUPd73TLOnBQQ-03QwA4 /k+Nme 
/66WIw+ZTLHYcTNalxiGYm@uQ== ; Key ID = 15903 

432000 IN RRSIG ( DNSKEY 13 1 432000 
20201202000000 20181128000000 15903 example. 
wwEo3ri6JBuCgx5b33w8axFWOhIen11+/mm8Isyc9FciuLhBiP+IgSgt+I1gc8 
9nR8zRpJpo1D6XR/qJxZgnfaA-- ) 

86400 IN DS ( 15903 13 2 7e0ebaf1cc0d309d4a73ca7d711719d 
d948f4da87b3d72865167658fc73ea577 ) 

86400 IN RRSIG ( DS 13 1 86400 20201202000000 
20181128000000 31918 . 
B5vx4zZaS+b0Yfz8PzpaPfk9VxxBvYbGj IvGhpUZV3diXzfCguXxNAJIT1Sz8 
e JX6BYT50PIrbG/N35U1sIskw== 


86488 IN DNSKEY ( 256 3 13 


ZKz+DCWkNA/vuheiVPcGqsH40U84KZA1rMRIyoz j 9WHzf8PsFp/oR8j 8vmj jW 
P98cbte4d8Nv1GL xzbUz03+FA== ; Key ID = 31918 


86488 IN DNSKEY ( 256 3 13 


8wMZZ41zHdyKZ4fv8kys/t30M1gvEadbsbygWrMhwddSXCZYGRrsAbPpireRW 
xbVcd1VtOrlFBcRDMTNOROXEQ-- ) ; Key ID = 2635 


86488 IN DNSKEY ( 257 3 13 


yvX*VNTUjxZiGvtr060hVbrPV9H6rVusQtF91lIxCFzbZOJxMQBFmbql1c8Xclv 
Q*gDOXnFOTsgs/frMmxyGOtRg-- ) ; Key ID - 47005 


86400 IN RRSIG ( DNSKEY 13 8 86400 20201202000000 


20181128000000 47005 . 
QEPW1ca-*N/ZhZPK1a77STG734cTeIOjUwq7eWOHsnOfudWmnCEVeco2wLLq9m 
nBT1dtNjIczvLG9pQTnOKUsHQ-- 
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